NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/7046

Internet Message Format | 1996-08-05 | 3.6 KB

Path: lyra.csx.cam.ac.uk!gpp10
From: [e-mail] (Giuliano Procida)
Newsgroups: comp.lang.misc,comp.lang.perl.misc,comp.lang.tcl,comp.lang.c,comp.lang.java
Subject: Re: Relative Speed of Perl vs. Tcl vs. C  [indentation]
Date: 17 Feb 1996 19:32:34 GMT
Organization: University of Cambridge, England
Message-ID: <4g5agi$[e-mail]>
References: <[e-mail]> <4g1h0a$[e-mail]> <[e-mail]>
NNTP-Posting-Host: ursa.cus.cam.ac.uk

In article <[e-mail]>,
Mark Tillotson <[e-mail]> wrote:
>[e-mail] (Hugh J.E. Davies) wrote:
>
>> I actually like code that structures blocks by indentation, since
[..]
>No no no no no.  The reasons why this is a fundamentally flawed idea
>are endless: linewrap, tabs, painful to automatically generate code,
>virtually impossible to stream-edit code, proportional fonts,
>breakable v. non-breakable spaces of differing widths, difficulty of
>cut-and-paste, impossible to use yacc-style tools, difficult to read
>out over the phone, hard to internationalize, sensitive to identity of
>newline character, macros, statements inside expressions, ...

If you take the view (as do Haskell etc) that "scoping via
indentation" is simply an abbreviation for a more explicit syntax
then most of your objections go away. Furthermore, it can arranged
that any extra work needed to parse programs written this way can be
done by the lexer (it just needs to insert an extra token
occasionally, see Haskell report for details). If indentation is not
just an abbreviation then I agree that things will be much harder with
existing technology.

Linewrap: ?
Tabs: lexer takes care of them
Auto-generate: taken care of (indentation is an abbreviation)
Stream-edit: as in sed? If so pipe it as: cat prog | unindent | sed
    ... | reindent > prog1 (where unindent unabbreviates the syntax
    and reindent re-abbreviates it)
Proportional fonts/uneven spaces: only a problem where used
    inappropriately (i.e., with a source editor that doesn't
    understand them)
Cut and paste: a decent source editor should take of this
Yacc: can still be used (see Gofer parser, for example)
Read over the phone: don't be silly, you just need to say when to pop
    and push indentation, or feed it through your syntax expander and
    then read it!
Internationalise: ?
Identity of newline: any compiler which counts lines for error
    messages knows damn well what a newline looks like!
Macros: (yuk) shouldn't be a problem if done post-lexer
Statements inside expressions: ?

I'm not sure what you meant in some of these cases. This is just off
the top of my head. I enjoy using indentation syntax; it may make
source processing a little harder but that is peanuts compared to the
extra clarity on-screen.

For most purposes an unindent and reindent would be the basic tools
necessary. If you also have an intelligent editor which likes using
proportional fonts you'll need to teach it about tabs stops as well.

>It is simply not a good idea, whitespace is too volatile to be a
>syntactic marker ...

Please explain.

>... and counting spaces is too far removed from language theory.

I could say the same thing about macros :-)

I don't think indentation is as awful as you have suggested, but then
I haven't met anyone in person who's tried it and really hates it.
If there is a real problem (like some source manipulation algorithms
become asymptotically slower) then I might change my mind.

Giuliano

ps Aren't Harlequin working on Haskell at the moment?
pps Haskell Report: ftp://dcs.gla.ac.uk/pub/haskell/report/